System for directing a transporation request to a driver with an inactive status based on exception criteria

ABSTRACT

In one embodiment an inactive status indication and one or more exception criteria are received from a computing device of a driver associated with a transportation service. A transportation request from a passenger associated with the transportation service is received. In response to a determination based on information included in the transportation request that the exception criteria is met, transportation request is directed to the driver.

TECHNICAL FIELD

This disclosure relates in general to the field of mobile applicationsand, more particularly, to a system for directing a transportationrequest to a driver with an inactive status based on exception criteria.

BACKGROUND

A transportation service may utilize a plurality of drivers that fulfillpassenger requests for transportation. A transportation service mayprovide one or more mobile applications that facilitate the efficientpairing of passengers and drivers. The transportation service mayreceive a transportation request and select a driver to fulfill therequest based on information associated with the transportation requestand information associated with the driver.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 illustrates a block diagram of a system for directing atransportation request to a driver with an inactive status based onexception criteria in accordance with certain embodiments.

FIG. 2 illustrates a block diagram of a passenger mobile device and adriver mobile device of the system of FIG. 1 in accordance with certainembodiments.

FIG. 3 illustrates a block diagram of a backend system of the system ofFIG. 1 in accordance with certain embodiments.

FIG. 4 illustrates a method for indicating an inactive status andreceiving a transportation request based on exception criteria inaccordance with certain embodiments.

FIG. 5 illustrates a method for receiving an inactive status and sendinga transportation request based on exception criteria in accordance withcertain embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

In one embodiment an inactive status indication and one or moreexception criteria are received from a computing device of a driverassociated with a transportation service. A transportation request froma passenger associated with the transportation service is received. Inresponse to a determination based on information included in thetransportation request that the exception criteria is met,transportation request is directed to the driver.

Example Embodiments

FIG. 1 illustrates a block diagram of a system 100 for directing atransportation request to a driver with an inactive status based onexception criteria in accordance with certain embodiments. Althoughvarious embodiments may include any number of drivers, passengers, andassociated devices, system 100 depicts two passengers having associatedpassenger mobile devices 104 and two drivers having associated drivermobile devices 108. The mobile devices are coupled through variousnetworks 120 to an application server 112 and a backend system 116.

Various embodiments of the present disclosure may enhance the experienceof drivers associated with a transportation service by allowing thedriver to indicate a status of the driver to a backend system 116associated with a transportation service. When the driver desires totake a break (e.g., to sleep, eat, drive home, or for another reason),he may indicate to the backend system 116 that his status is inactive.The driver may also indicate one or more exception criteria. The backendsystem 116 receives the indication of the driver's inactive status andthe exception criteria and configures itself to only send transportationrequests that satisfy the exception criteria to the driver while thedriver remains inactive. Thus, the driver may avoid receivingtransportation requests during his inactive state unless the request isparticularly desirable according to criteria set by the driver. Variousembodiments may provide technical advantages such as minimizing theworkload on the backend system 116 and driver mobile devices 108 byreducing the sending of requests that are unlikely to be accepted bydrivers and rapid determination of whether a driver should beinterrupted with a particular transportation request.

Mobile devices 104 and 108 may include any electronic computing deviceoperable to receive, transmit, process, and store any appropriate data.For example, mobile devices 104 and 108 may include laptop computers,tablet computers, smartphones, personal digital assistants, and otherdevices capable of connecting (e.g., wirelessly) to one or more networks120. Mobile devices 104 and 108 may include a set of programs such asoperating systems (e.g., Microsoft Windows, Linux, Android, Mac OSX,Apple iOS, UNIX, or similar operating system), applications, plug-ins,applets, virtual machines, machine images, drivers, executable files,and other software-based programs capable of being run, executed, orotherwise used by the respective devices. Each mobile device can includeat least one graphical display and user interface allowing a user toview and interact with applications and other programs of the mobiledevice. In a particular embodiment, driver mobile devices may be ahardened device that is configured to only run a driver applicationusing a specialized operating system (e.g., a modified version ofAndroid). In one embodiment, a transportation service may issue orotherwise facilitate the provision of hardened devices to its drivers,but restrict the functionality of the devices to the driver application(i.e., the devices may be locked down so as not to allow theinstallation of additional applications).

In various embodiments, a driver mobile device 108 may be integratedwithin and/or communicate with a self-driven vehicle (e.g., a vehiclethat has the capability of driving without physical steering guidancefrom a human being) and may influence the movement of the vehicle byproviding route information (e.g., passenger pick-up and destinationlocations or driver destination locations) to the self-driven vehicle.Accordingly, as used herein “driver” may refer to a human being that mayphysically drive or otherwise control movement of a vehicle or thevehicle itself (e.g., in the case of a self-driven vehicle) or componentthereof (e.g., mobile device application 108 or logic therein).

In particular embodiments, a passenger application runs on passengermobile devices 104. The application may allow a user to enter variousaccount information (e.g., in connection with a registration with thetransportation service) to be utilized by a transportation service. Forexample, the account information may include a user name and password(or other login credentials), contact information of the user (e.g.,phone number, home address), payment information (e.g., credit cardnumbers and associated information), or car preference information(e.g., what models or color of car the user prefers).

The application may allow a user to request a ride from thetransportation service. In various embodiments, the application mayestablish a pick-up location automatically or based on user input (e.g.,locations may include the current location of the mobile device 104 asdetermined by a global positioning system (GPS) of the mobile device ora different user-specified location). In certain embodiments, the usermay specify a destination location as well. The locations may bespecified in any suitable format, such as GPS coordinates, streetaddress, establishment name (e.g., LaGuardia Airport, Central Park,etc.), or other suitable format. At any time (e.g., before the ride,during the ride, or after the ride is complete) the user may specify amethod of payment to be used for the ride. The user may also specifywhether the request is for immediate pick-up or for a specified time inthe future. In various embodiments, the user may specify pick-up by avehicle that has particular merchandise available for use by the user,such as a specified type of battery charger, bottle of water or otherfood or beverage, umbrella, or other suitable merchandise. The user mayalso specify criteria for the driver, such as a minimum performancerating, such that drivers having performance ratings below the minimumperformance rating will not be considered during selection of thedriver.

The user may use the application to order a ride based on the specifiedinformation. The request for the ride is generated based on theinformation and transmitted to backend system 116. Backend system 116will facilitate the selection of a driver. In some embodiments, backendsystem 116 may select a driver based on any suitable factors, such asthe information contained in the request from the passenger, theproximity of the driver to the passenger, or other suitable factors. Inother embodiments, backend system 116 may select a plurality of driversthat could fulfill the ride request, send information associated withthe drivers to the passenger, and allow the passenger to select thedriver to be used via the application on the passenger mobile device104. Any suitable information about the potential driver(s) may be sentto the mobile device 104 either before or after the selection of thedriver by the passenger, such as a location of a driver, an estimatedpick-up time, a type of car used by a driver, the merchandise availablein the car, driver ratings or comments from other passengers about thedriver, or other suitable information.

Once a driver has been selected and has accepted the request to providea ride, the application may notify the user of the selected driver andprovide real-time updates of the driver's location (e.g., with respectto the passenger's location) and estimated pick-up time. The applicationmay also provide contact information for the driver and/or the abilityto contact the driver through the application (e.g., via a phone call ortext). Once the ride has begun, the application may display any suitableinformation, such as the current location of the mobile device 104 andthe route to be taken. Upon completion of the ride, the application mayprovide the passenger the ability to rate the driver or provide commentsabout the driver.

In particular embodiments, a driver application runs on driver mobiledevices 108. The application may allow a driver to enter various accountinformation to be utilized by a transportation service. For example, theaccount information may include a user name and password (or other logincredentials), contact information of the driver (e.g., phone number,home address), information used to collect payment (e.g., bank accountinformation), vehicle information (e.g., what model or color of car thedriver utilizes), merchandise offered by the driver, or other suitableinformation.

In various embodiments, the application may allow a driver to specifyhis availability to transport passengers for the transportation service.In some embodiments, the driver may select between multiple levels ofavailability. In one example, the driver may be “available,” meaningthat the driver is willing to receive and consider any transportationrequests that the transportation service sends the driver; the drivermay be “unavailable,” meaning that the driver is not willing to receiveany transportation requests (e.g., this state may be explicitlyindicated by the driver inputting this state into his mobile device orby a deduction that the driver's device is not logged in to thetransportation service through the driver application), or the drivermay be “inactive,” meaning that the driver only desires to receiveparticular requests meeting certain exception criteria.

The application may periodically transmit the current location of themobile device 108 as determined by a GPS of the mobile device 108 to thebackend system 116. When a driver is selected to provide a ride, backendsystem 116 may send a notification to the driver application. In someembodiments, the driver may have a limited amount of time to selectwhether the driver accepts the ride. In other embodiments, theapplication may be configured by the driver to automatically accept theride or to automatically accept the ride if certain criteria are met(e.g., fare minimum, direction of travel, minimum passenger rating,etc.).

Once a pairing of the driver and the passenger is confirmed, theapplication may navigate the driver to the passenger. The applicationmay also provide contact information for the passenger and/or theability to contact the passenger through the application (e.g., via aphone call or text). The application may also navigate the driver to thepassenger's destination once the ride begins. Upon completion of theride, the application may provide the driver the ability to rate thepassenger or provide comments about the passenger.

System 100 may include one or more application servers 112 coupled tothe mobile devices through one or more networks 120. The passengerapplication and driver application may be supported with, downloadedfrom, served by, or otherwise provided through an application server 112or other suitable means. In some instances, the applications can bedownloaded from an application storefront onto a particular mobiledevice using storefronts such as Google Android Market, Apple App Store,Palm Software Store and App Catalog, RIM App World, etc., as well asother sources. In various embodiments, the passenger application anddriver application may be installed on their respective devices in anysuitable manner and at any suitable time. As one example, a passengerapplication may be installed on a mobile device as part of a suite ofapplications that are pre-installed prior to provision of the mobiledevice to a consumer. As another example, a driver application may beinstalled on a mobile device by a transportation service (or an entitythat provisions mobile devices for the transportation service) prior tothe issuance of the device to a driver that is employed or otherwiseassociated with the transportation service.

As described above, applications utilized by mobile devices 104 and 108can make use of a backend system 116. Backend system 116 may compriseany suitable servers or other computing devices that facilitate theprovision of a transportation service as described herein. For example,backend system 116 may receive a request from a passenger and facilitatethe assignment of a driver to fulfill the request. Backend system 116 isdescribed in more detail in connection with FIG. 3.

In general, “servers,” and other “computing devices” may includeelectronic computing devices operable to receive, transmit, process,store, or manage data and information associated with system 100. Asused in this document, the term “computing device,” is intended toencompass any suitable processing device. For example, portions ofsystem 100 may be implemented using computers other than servers,including server pools. Further, any, all, or some of the computingdevices may be adapted to execute any operating system, including Linux,UNIX, Windows Server, etc., as well as virtual machines adapted tovirtualize execution of a particular operating system, includingcustomized and proprietary operating systems.

Further, servers and other computing devices of system 100 can eachinclude one or more processors, computer-readable memory, and one ormore interfaces, among other features and hardware. Servers can includeany suitable software component or module, or computing device(s)capable of hosting and/or serving a software application or services(e.g., services of application server 112 or backend system 116),including distributed, enterprise, or cloud-based software applications,data, and services. For instance, servers can be configured to host,serve, or otherwise manage data sets, or applications interfacing,coordinating with, or dependent on or used by other services, includingtransportation service applications and software tools. In someinstances, a server, system, subsystem, or computing device can beimplemented as some combination of devices that can be hosted on acommon computing system, server, server pool, or cloud computingenvironment and share computing resources, including shared memory,processors, and interfaces.

In various embodiments, backend system 116 or any components thereof maybe deployed using a cloud service such as Amazon Web Services, MicrosoftAzure, or Google Cloud Platform. For example, the functionality of thebackend system 116 may be provided by virtual machine servers that aredeployed for the purpose of providing such functionality or may beprovided by a service that runs on an existing platform.

System 100 also includes various networks 120 used to communicate databetween the mobile devices 104 and 108, the backend system 116, and theapplication server 112. The networks 120 described herein may be anysuitable network or combination of one or more networks operating usingone or more suitable networking protocols. A network may represent aseries of points, nodes, or network elements and interconnectedcommunication paths for receiving and transmitting packets ofinformation. For example, a network may include one or more routers,switches, firewalls, security appliances, antivirus servers, or otheruseful network elements. A network may provide a communicative interfacebetween sources and/or hosts, and may comprise any public or privatenetwork, such as a local area network (LAN), wireless local area network(WLAN), metropolitan area network (MAN), Intranet, Extranet, Internet,wide area network (WAN), virtual private network (VPN), cellular network(implementing GSM, CDMA, 3G, 4G, LTE, etc.), or any other appropriatearchitecture or system that facilitates communications in a networkenvironment depending on the network topology. A network can compriseany number of hardware or software elements coupled to (and incommunication with) each other through a communications medium. In someembodiments, a network may simply comprise a transmission medium such asa cable (e.g., an Ethernet cable), air, or other transmission medium.

FIG. 2 illustrates a block diagram of a passenger mobile device 104 anda driver mobile device 108 of the system of FIG. 1 in accordance withcertain embodiments. In the embodiment shown, the devices may becommunicatively coupled through network 120 f which may include anysuitable intermediary nodes, such as a backend system 116.

In the embodiment depicted, mobile devices 104 and 108 each include acomputer system to facilitate performance of their respectiveoperations. In particular embodiments, a computer system may include aprocessor, storage, and one or more communication interfaces, amongother components. As an example, mobile devices 104 and 108 each includeone or more processors 202 and 204, memory elements 206 and 208, andcommunication interfaces 214 and 216, among other hardware and software.These components may work together in order to provide functionalitydescribed herein.

Processors 202 and 204 may be a microprocessor, controller, or any othersuitable computing device, resource, or combination of hardware, storedsoftware and/or encoded logic operable to provide, either alone or inconjunction with other components of mobile devices 104 and 108, thefunctionality of these mobile devices. In particular embodiments, mobiledevices 104 and 108 may utilize multiple processors to perform thefunctions described herein.

A processor can execute any type of instructions to achieve theoperations detailed in this Specification. In one example, the processorcould transform an element or an article (e.g., data) from one state orthing to another state or thing. In another example, the activitiesoutlined herein may be implemented with fixed logic or programmablelogic (e.g., software/computer instructions executed by the processor)and the elements identified herein could be some type of a programmableprocessor, programmable digital logic (e.g., a field programmable gatearray (FPGA), an erasable programmable read only memory (EPROM), anelectrically erasable programmable ROM (EEPROM)) or an ASIC thatincludes digital logic, software, code, electronic instructions, or anysuitable combination thereof.

Memory 206 and 208 may comprise any form of non-volatile or volatilememory including, without limitation, random access memory (RAM),read-only memory (ROM), magnetic media (e.g., one or more disk or tapedrives), optical media, solid state memory (e.g., flash memory),removable media, or any other suitable local or remote memory componentor components. Memory 206 and 208 may store any suitable data orinformation utilized by mobile devices 104 and 108, including softwareembedded in a computer readable medium, and/or encoded logicincorporated in hardware or otherwise stored (e.g., firmware). Memory206 and 208 may also store the results and/or intermediate results ofthe various calculations and determinations performed by processors 202and 204.

Communication interfaces 214 and 216 may be used for the communicationof signaling and/or data between mobile devices 104 and 108 and one ormore networks (e.g., 120 f) and/or network nodes (e.g., backend system116 and application server 112) coupled to a network or othercommunication channel. For example, communication interfaces 214 and 216may be used to send and receive network traffic such as data packets.Each communication interface 214 and 216 may send and receive dataand/or signals according to a distinct standard such as an LTE, IEEE802.11, IEEE 802.3, or other suitable standard. Communication interfaces214 and 216 may include antennae and other hardware for transmitting andreceiving radio signals to and from other devices in connection with awireless communication session over one or more networks 120.

GPS units 210 and 212 may include any suitable hardware and/or softwarefor detecting a location of their respective mobile devices 104 and 108.For example, a GPS unit may comprise a system that receives informationfrom GPS satellites, wireless or cellular base stations, and/or othersuitable source and calculates a location based on this information (orreceives a calculated position from a remote source). In one embodiment,the GPS unit is embodied in a GPS chip.

Application logic 218 may include logic providing, at least in part, thefunctionality of the passenger application described herein. Similarly,application logic 220 may include logic providing, at least in part, thefunctionality of the driver application described herein. In aparticular embodiment, the logic of devices 104 and 108 may includesoftware that is executed by processor 202 and 204. However, “logic” asused herein, may include but not be limited to hardware, firmware,software and/or combinations of each to perform a function(s) or anaction(s), and/or to cause a function or action from another logic,method, and/or system. In various embodiments, logic may include asoftware controlled microprocessor, discrete logic (e.g., an applicationspecific integrated circuit (ASIC)), a programmed logic device (e.g., afield programmable gate array (FPGA)), a memory device containinginstructions, combinations of logic devices, or the like. Logic mayinclude one or more gates, combinations of gates, or other circuitcomponents. Logic may also be fully embodied as software.

In various embodiments of the present disclosure, in addition to anycombination of the features described above with respect to thepassenger application, application logic 218 may provide additionalfeatures for the passenger application to enhance a passenger'sexperience.

In a particular embodiment, a user may supply login credentials for asocial network system (e.g., FACEBOOK) or other social media system(e.g., TWITTER) to the transportation service through application logic218. The transportation service (e.g., through backend server) may thenaccess the user's account on the social network system or other socialmedia system and access information associated with the user's account.As another example, passenger application logic 218 may access theuser's social media account directly and integrate information from theaccount with other functionality of the passenger application logic.

Social network application logic 222 may provide a user interface toallow a passenger to interact with (e.g., enter and transmit informationto and view information received from) a social network system. A socialnetwork system may store a record (i.e., a user profile) for each userof the system. The user profile may include any suitable informationabout the user, such as contact information, employment information,demographic information, personal interests, user-generated content, orother suitable information. The social network system may also store arecord of the user's relationship with other users of the social networksystem. For example, such information may be stored as a social graph,wherein users (e.g., individuals, groups, business entities,organizations, etc.) may be represented as nodes in the graph and thenodes may be connected based on relationships between the users. Asocial network system may provide various services (e.g., photo sharing,wall posts, messaging, games, or advertisements) facilitatinginteraction between the users.

In various embodiments, the social network system may interact withpassenger application logic 218 or backend server 302 to enhance thefunctionality of these components. As an example, background informationassociated with a passenger may be obtained by a backend server 302 andused to determine whether to route a request from the passenger to aparticular driver.

In various embodiments, the social network system may provide any of thefunctionality listed above with respect to passenger application logic218 in allowing a user to request a ride and may relay received requestsfor rides to backend server 302 along with any suitable identifyinginformation about the user to facilitate pickup by a driver.

In various embodiments of the present disclosure, in addition to anycombination of the features described above with respect to the driverapplication, driver application logic 220 may provide additionalfeatures for the driver application to enhance the functionality of thetransportation service. For example, driver application logic 220 mayallow the driver to enter an availability status, such as available, notavailable, or inactive, as described above. In various embodiments,driver application logic 220 may also allow the driver to enterinformation associated with an inactive status, such as a duration ofthe status or exception criteria and may transmit the status indicationand any associated information to the backend system 116. The durationof the status may be indicated in any suitable manner. For example, thedriver may specify a time (e.g., a finite time duration or an end time)indicating when the inactive status should end and the driver's statusshould return to available. As another example, if the driver istraveling to a destination location, the driver may indicate that theinactive status should end when the driver arrives at the destinationlocation. In various embodiments, the driver may indicate his status asinactive at the time that he desires to enter the inactive status (e.g.,by interacting with an interface of his mobile device to explicitlyenter his status). In other embodiments, the driver may schedule thestart and/or end of an inactive status (which may be a one-timescheduling or a periodic scheduling). For example, the driver may usedriver application logic 220 to enter an inactive status from 5:00 to6:00 each day in connection with the driver's commute home or from 12:00to 1:00 in connection with the driver's lunch time. In variousembodiments, driver application logic 220 may provide fields denoting“lunch” and “commute home” (or similar labels) for the driver to entertimes associated with his daily commute and/or lunch time and mayautomatically trigger the inactive status at the appropriate time eachday.

Driver application logic 220 may also provide an interface for allowingthe driver to specify exception criteria associated with his inactivestatus. When a driver enters an inactive status, the backend system 116will withhold sending transportation requests to the driver unless thespecified exception criteria is met. The driver may enter any suitablecriteria and may specify which conditions and how many conditions mustbe met before a transportation request is sent to the driver in anysuitable manner. For example, the driver may specify a multipledifferent criteria and indicate that when any one of the criteria ismet, requests may be sent to the driver. As another example, the drivermay specify multiple different criteria and indicate that all thecriteria must be met before requests are sent to the driver. As anotherexample, the driver may specify a single criterion that must be metbefore requests are sent to the driver. As yet another example, thedriver may specify multiple criteria and indicate that a certain numberof criteria be met or that one or more particular combinations ofcriteria be met before transportation requests are sent to the driver.

Any suitable criteria may be specified by the driver. In one example, acriterion may be that a minimum cost (e.g., actual or expected cost) forthe ride specified by the transportation request must be met orexceeded. In another example, a criterion may be that a minimum averagecost (e.g., actual or expected cost per unit of time or per unit ofdistance) for the ride specified by the transportation request must bemet or exceeded. In some embodiments this cost may be averaged over theexpected time required for the ride itself or may also be averaged overadditional travel time to and/or from the ride for the driver. Inanother example, a criterion may include a time length or a distance tobe compared against an expected duration of the ride (which again may ormay not also include travel to and/or from the pickup or destinationlocation of the ride). For example, the driver may only want rides ofshorter duration or may only want rides of longer duration. In anotherexample, a criterion may specify a location. For example, the driver mayspecify that he only wants transportation requests that will take himcloser to or within a specified distance of a specified location. Asanother example, the driver may specify that he only wantstransportation requests specifying a pickup location that is within aspecified distance of the driver's current location. In another example,a criterion may include a type of route. For example, the driver mayspecify a preference for city driving versus highway driving (or viceversa) and the criterion is only met when a majority (or other specifiedamount) of the drive will be in the city (or highway). In anotherexample, a criterion may include one or more characteristics associatedwith the passenger. In various embodiments, the specifiedcharacteristics may be obtained from a social network profile of thepassenger or the passenger account data 316. For example, the driver mayspecify that he would only like to provide rides to passengers fromother locales (who may be likely to be tourists), to passengers fromcertain geographic areas, to passengers having a minimum specifiedpassenger rating, or passengers with any other suitable criteria.

In various embodiments, when the one or more specified exceptioncriteria is met and the driver receives a transportation request duringa period in which the driver is in an inactive status, the driver mayconcurrently receive a notification as to which criteria were met. Forexample, a criterion as well as a value (e.g., cost, distance) of thetransportation request corresponding to that criterion may be providedto the driver via driver application logic 220. In some embodiments, thedriver may select to forego notification of the exception criterion(e.g., in favor of a standard view that is provided when atransportation request is received).

In various embodiments, the driver may be prompted to enter exceptioncriteria when the driver uses driver application logic 220 to indicatethat the driver's status is inactive. In some embodiments, driverapplication logic 220 (and/or backend server 302) may store previouslyentered exception criteria and associate that criteria with a currentinactive status or allow the driver to update the stored criteria andassociate the updated criteria with the current inactive status.

In various embodiments, instead of transferring the indication of theinactive status and associated exception criteria to the backend system116, the driver application logic 220 may store this information locally(e.g., on mobile device 108). When a transportation request is directedto the mobile device 108, the driver application logic 220 may check therequest to determine whether the exception criteria are met. If thecriteria are not met, the driver application logic 220 may reject therequest without requiring interaction from the driver. In at least someembodiments, the driver application logic 220 may forego presentation ofthe transportation request to the driver if the exception criteria arenot met. If the exception criteria are met, the driver application logic220 may present the transportation request to the driver and wait forthe driver to indicate whether the driver would like to take the request(or in some embodiments may automatically accept the request on thedriver's behalf) and may send the backend system 116 an indication thatthe ride has been accepted or rejected. Such embodiments, may ease theburden on the backend system by distributing the logic associated withthe inactive status among the mobile devices of the various drivers.

FIG. 3 illustrates a block diagram of a backend system 116 of the systemof FIG. 1 in accordance with certain embodiments. Although FIG. 3depicts a particular implementation of the backend system 116, thebackend system may include any suitable devices to facilitate theoperation of the transportation service described herein. In theembodiment depicted, backend system includes backend server 302, datastore 304, and third party services 306 coupled together by network 120g. In various embodiments, backend server 302, data store 304, and/orthird party services 306 may each comprise one or more physical devices(e.g., servers or other computing devices) providing the functionalitydescribed herein. In some embodiments, one or more of backend server302, data store 304, and third party services 306 (or portions thereof)are deployed using a cloud service and may comprise one or more virtualmachines or containers.

In the embodiment depicted, backend server 302 includes a computersystem to facilitate performance of its operations. As an example,backend server 302 includes one or more processors 308, memory elements310, and communication interfaces 312, among other hardware andsoftware. These components may work together in order to provide backendserver functionality described herein. Processor 308 may have anysuitable characteristics of the processors 202 and 204 described above.In particular embodiments, backend server 302 may utilize multipleprocessors to perform the functions described herein. In variousembodiments, reference to a processor may refer to multiple discreteprocessors communicatively coupled together.

Similarly, memory 310 may have any suitable characteristics of memories206 and 208 described above. Memory 310 may store any suitable data orinformation utilized by backend server 302, including software embeddedin a computer readable medium, and/or encoded logic incorporated inhardware or otherwise stored (e.g., firmware). Memory 310 may also storethe results and/or intermediate results of the various calculations anddeterminations performed by processor 308.

Communication interface 312 may also have any suitable characteristicsof communication interfaces 214 and 216 described above. Communicationinterfaces 312 may be used for the communication of signaling and/ordata between backend server 302 and one or more networks (e.g., networks120) and/or network nodes (e.g., mobile devices 104 and 108, data store304, third party services 306, and application server 112) coupled to anetwork or other communication channel.

Business logic 314 may have any suitable characteristics of applicationlogic 218 and 220 described above. Business logic 314 may include logicproviding, at least in part, the functionality of the backend serverdescribed herein. In a particular embodiment, business logic 314 mayinclude software that is executed by processor 308. However, in otherembodiments, business logic 314 may take other forms such as thosedescribed above with respect to application logic 218 and 220.

Backend server 302 may communicate with data store 304 to initiatestorage and retrieval of data related to the transportation service.Data store 304, may store any suitable data associated with thetransportation service in any suitable format(s). For example, datastore 304 may include one or more database management systems (DBMS),such as SQL Server, Oracle, Sybase, IBM DB2, or NoSQL data bases (e.g.,Redis and MongoDB).

In the embodiment depicted, data store 304 includes passenger accountdata 316, driver account data 318, transportation request data 320,driver availability data 322, navigational data 324, and historicalrequest data 326. The various data may be updated at any suitableintervals.

Passenger account data 316 may include any suitable informationassociated with passenger accounts, such as contact information (e.g.,real names and addresses), user names and passwords (or otherauthentication information), payment information (e.g., credit card orbank account numbers and associated information), passenger preferences(e.g., preferred type or color of car), ratings the passenger has givendrivers, ratings the passenger has received from drivers, or otherinformation associated with passenger profiles.

Driver account data 318 may include any suitable information associatedwith driver accounts, such as contact information (e.g., real names andaddresses), user names and passwords (or other authenticationinformation), payment collection information (e.g., bank accountinformation), vehicle information (e.g., models and colors of cars thedrivers utilize, maximum capacity of the cars of the drivers),merchandise offered by the drivers, whether the drivers are available totransport passengers, whether the drivers have opted for automaticacceptance of transportation requests (whereby the backend server 302may assign a transportation request to the driver without waiting forthe driver to indicate acceptance of a request), or other suitableinformation.

Transportation request data 320 may comprise pending requests (i.e.,requests that have not yet been fulfilled) received from passengers.Each request may include any suitable information, such as anycombination of one or more of an identification of the passenger makingthe request, the time the request was made, the current location of thepassenger, the desired pick-up location, the desired pick-up time, theestimated time remaining until a driver can pick up the passenger, theactual pick-up time, the desired destination location of the passenger(which the passenger may or may not provide at the time the request ismade), the expected arrival time at the destination location, the typeof vehicle requested, estimated fare for the trip, current accumulatedfare for the trip, estimated time and mileage remaining in the trip,other information specified by the user (e.g., requested merchandise,requested minimum rating of driver), whether a driver has been assignedto a request, and which driver has been assigned to a request.

Driver availability data 322 may comprise information associated withdrivers that are available to transport passengers. In some embodiments,driver availability data 322 may also comprise information associatedwith drivers that are not available to transport passengers (e.g.,because they are off-duty or currently transporting a passenger). Anentry in the driver availability data 322 may include an identificationof a driver and any suitable associated information, such as one or moreof a current location of the driver, whether the driver is available totransport passengers, whether the driver is currently transporting apassenger, a destination location of a current trip of the driver, anestimate of how long it will be before the driver finishes his currenttrip, whether the driver has opted for automatic acceptance oftransportation requests, or other suitable information.

Navigational data 324 may comprise information supporting navigationfunctions provided by the passenger applications and driver passengerapplications. For example, navigational data 324 may comprise map datathat may be sent to passenger mobile devices 104 and driver mobiledevices 108 to allow the devices to display maps and associatedindicators (e.g., location of passenger(s), location of driver(s),desired routes, etc.) In some embodiments, the navigational data mayalso comprise information indicative of the amount of time required totravel between various locations. In some embodiments, navigational data324 may comprise historic and/or real time data about the flow oftraffic in particular areas enabling backend server 302 to calculate anestimated time required to travel from one location to another.

Historical request data 326 may comprise information about completedrequests. In some embodiments, historical request data 326 may alsoinclude information about canceled requests. The information for eachrequest may include any combination of the information listed above withrespect to requests stored in the transportation request data 320 aswell as any combination of additional data such as the time at which thedestination location was reached, the total time of the trip, the totalfare, a rating given by the passenger to the driver or by the driver tothe passenger for the trip, or other suitable information associatedwith the trip.

In various embodiments, backend server 302 may access third partyservices 306 through business logic 328 to access data 330. Third partyservices 306 may represent any suitable number of devices operated byany suitable number of third parties that are distinct from an entitythat operates the backend system 116 and/or data store 304. For example,in some embodiments the navigational data may be obtained from a thirdparty service 306 rather than data store 304, or additional third partynavigational data such as map data or historical and/or current trafficflow information may be used to supplement navigational data 324. Asanother example, third party services 306 may authenticate users onbehalf of the backend server 302 (e.g., through an account of the userwith the third party). Business logic 328 may comprise any suitablelogic operable to receive requests for data from backend system 116and/or mobile devices 104 and 108 and provide responses to the requests.

Backend server 302 may be in communication with each passenger mobiledevice 104 and each driver mobile device 108 that is utilizing thetransportation service at a particular time. Backend server may storeinformation received from the mobile devices 104 and 108 in data store304. Backend server 302 may also receive and respond to requests made bymobile devices 104 and 108 by processing information retrieved from datastore 304.

When a passenger opens the passenger application, the backend server 302may log the passenger in based on a comparison of authenticationinformation provided by the passenger mobile device 104 withauthentication information stored in passenger account data 316. Thepassenger may then request a ride. The request is received by thebackend server 302 and stored in transportation request data 320.Backend server 302 may access driver availability data 322 to determineone or more drivers that would be suitable to fulfill the request fromthe passenger. In one embodiment, backend server 302 selects aparticular driver (e.g., based on the driver's locality with respect tothe passenger's pick-up location) and sends information associated withthe request to the driver. The driver indicates whether he accepts orrejects the request via his mobile device 108. If the driver rejects therequest, backend server 302 selects a different driver and the processis repeated until the backend server 302 receives an accepted requestfrom a driver. In another embodiment, backend server 302 may select aplurality of drivers that may fulfill a passenger's request and allowthe passenger to select one of the drivers. The backend server 302 mayproceed to notify the driver of the request in a similar manner to thatdescribed above. In yet another embodiment, backend server 302 mayselect a plurality of drivers that may fulfill a passenger's request andnotify each driver of the passenger's request. The backend server 302may then allocate the request to one of the drivers based on anysuitable criteria. For example, the driver who is the first to acceptthe request may be assigned to the request. As another example, ifmultiple drivers accept the request within a given timeframe, therequest may be assigned to the most suitable driver (e.g., the driverthat is closest to the pick-up location or a driver that has a car thatmeets preferred characteristics of the passenger's request).

Once the request has been accepted by a driver, the backend server 302notifies the passenger that a driver has accepted his request andprovides any suitable information associated with the driver (e.g.,driver's current location, model and color of vehicle, estimated time ofarrival, etc.) to the passenger.

The backend server 302 may provide navigation information to the drivermobile device 108 to direct the driver to the passenger's pickuplocation and subsequently to direct the driver to the passenger'sdestination location. The backend server 302 may also provide real-timeupdates associated with the trip to both the passenger and the driver.

Once the passenger's destination location has been reached, the backendserver 302 may facilitate payment of the fare for the trip using paymentinformation stored in passenger account data 316 and/or driver accountdata 318 (or information supplied by the passenger at the time of thetransaction). The backend server 302 may also receive ratings associatedwith the trip for the passenger and driver and store these ratings indata store 304.

Backend server 302 may be operable to track the status of driversassociated with the transportation service and adjust the sending oftransportation requests to the drivers based on their status. In someembodiments, backend server 302 may receive inactive status indicationsand one or more associated exception criteria from computing devices(e.g., 108) of the drivers. When an inactive status indication andassociated exception criteria are received, backend server 302 may storethis information in the data store 304 (e.g., in driver availabilitydata 322).

The backend server 302 may use this information in any suitable mannerin determining whether to send a particular transportation request to aparticular driver. For example, in one embodiment, backend server 302may exclude drivers with an inactive status from an initial search for asuitable driver for a particular transportation request and check theexception criteria of drivers with an inactive status only if no othersuitable driver is found. As another example, drivers with an inactivestatus may be included in the initial search for one or more suitabledrivers, and their exception criteria checked if they are selected as asuitable driver. As yet another example, the backend server could firstdetermine whether exception criteria is met for a plurality of inactivedrivers, and then include the inactive drivers with satisfied exceptioncriteria in a search for a suitable driver. The exception criteria maybe checked in any suitable manner by backend server 302, for example, byparsing information from the transportation request or other informationassociated with the passenger (e.g., passenger account data or a socialnetwork profile of the passenger) and comparing it against the criteriareceived from the drivers.

In any event, if the backend server 302 determines that a driver withinactive status has specified exception criteria that is met by thetransportation request and that the driver is a suitable candidate tofulfill the request, the transportation request may be directed to thedriver. If the backend server 302 determines that the exception criteriafor a driver has not been met, then the backend server 302 removes thedriver from consideration for fulfilling the transportation request anddoes not send the transportation request to the driver.

In various embodiments, backend server 302 may process a transportationrequest differently for drivers having an inactive status (as comparedto drivers with an active status). For example, in one embodiment, thebackend server 302 may offer a driver with an inactive status less timeto respond as to whether the driver accepts the transportation requestbefore offering the request to a different driver (because drivers whohave indicated an inactive status may be less apt to monitor incomingrequests). As another example, the backend server 302 may take one ormore of the exception criteria into account in setting a price for thetransportation request. For example, if the only suitable driver for aparticular transportation request currently has an inactive status buthas specified an exception criterion of a certain price or averageprice, the backend server 302 may advertise to the passenger a pricethat is higher than the price that would normally be charged (e.g., abaseline price) for a similar ride in order to facilitate the provisionof the ride by the driver. For example, when the transportation usesdynamic pricing (i.e., sets prices based on demand), a driver may usethe exception criteria to indicate that he will only take a ride if acertain price is met of if a price per distance unit or time unit isabove a certain threshold, and the backend server may take thisindication into account when setting the price for the ride.

FIG. 4 illustrates a method 400 for indicating an inactive status andreceiving a transportation request based on exception criteria inaccordance with certain embodiments. The steps of FIG. 4 may beperformed, for example, by a mobile device 108.

At step 402, one or more exception criteria are received from a driver.At step 404, a request is received from the driver to enter inactivemode. In various embodiments, the exception criteria may be enteredbefore or after the request to enter inactive mode is received. At step406, an inactive status indication and the exception criteria are sentto a server, such as backend server 302.

At step 408, a transportation request that meets the exception criteriais received (e.g., from the server). The driver may decide whether toaccept the transportation request. Additional transportation requestsmay be received while the driver is inactive, provided they meet theexception criteria. At step 410, a request to resume normal (e.g.,“available”) mode is received. As an example, the driver may enter therequest at the time that the driver wishes the status to be changed. Asanother example, logic of the mobile device 108 may generate the requestin response to a detection that an end time of a scheduled inactivestatus has been reached. At step 412, a normal status indication is sentto the server (e.g., backend server 302) to set the status of the driverback to available.

Some of the steps illustrated in FIG. 4 may be repeated, combined,modified or deleted where appropriate, and additional steps may also beincluded. Additionally, steps may be performed in any suitable order orconcurrently without departing from the scope of particular embodiments.

FIG. 5 illustrates a method 500 for receiving an inactive status andsending a transportation request based on exception criteria inaccordance with certain embodiments. The steps of FIG. 4 may beperformed, for example, by a backend server 302.

At step 502, an inactive status indication and exception criteria arereceived are received from a mobile device of a driver. At step 504, thedriver's status and exception criteria are updated (e.g., within datastore 304). At step 506, a transportation request is received from apassenger.

At step 508, it is determined whether the driver is a good candidate toservice the request. If the driver is not a good candidate (e.g., adifferent driver is near the passenger and has a status of available),the method ends. If the driver is a good candidate, then it isdetermined whether the driver's exception criteria are met. If they arenot met, the transportation request is sent to a different driver atstep 512 and the method ends. If the exception criteria are met, thetransportation request is sent to the driver.

Some of the steps illustrated in FIG. 5 may be repeated, combined,modified or deleted where appropriate, and additional steps may also beincluded. Additionally, steps may be performed in any suitable order orconcurrently without departing from the scope of particular embodiments.

It is also important to note that the steps in FIGS. 4-5 illustrate onlysome of the possible scenarios that may be executed by, or within, thevarious components of the system described herein. Some of these stepsmay be deleted or removed where appropriate, or these steps may bemodified or changed considerably without departing from the scope of thepresent disclosure. In addition, a number of these operations may havebeen described as being executed concurrently with, or in parallel to,one or more additional operations. However, the timing of theseoperations may be altered considerably. The preceding operational flowshave been offered for purposes of example and discussion.

The functionality described herein may also be performed by any suitablecomponent of the system. For example, certain functionality describedherein as being performed by backend server 116, may, in variousembodiments, be performed by any combination of one or more passengermobile devices 104 or driver mobile devices 108 where appropriate.Similarly, certain functionality described herein as being performed bya passenger mobile device 104 or a driver mobile device 108 may, invarious embodiments, be performed by backend server 116 whereappropriate.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims. In order to assist the UnitedStates Patent and Trademark Office (USPTO) and, additionally, anyreaders of any patent issued on this application in interpreting theclaims appended hereto, Applicant wishes to note that the Applicant: (a)does not intend any of the appended claims to invoke paragraph six (6)of 35 U.S.C. section 112 as it exists on the date of the filing hereofunless the words “means for” or “step for” are specifically used in theparticular claims; and (b) does not intend, by any statement in thespecification, to limit this disclosure in any way that is not otherwisereflected in the appended claims.

What is claimed is:
 1. A method comprising: receiving an inactive statusindication and one or more exception criteria from a computing device ofa driver associated with a transportation service; receiving atransportation request from a passenger associated with thetransportation service; and in response to a determination based oninformation included in the transportation request that the exceptioncriteria is met, directing the transportation request to the driver. 2.The method of claim 1, further comprising determining that the driver isa suitable candidate for the transportation request prior to thedetermination that the exception is met.
 3. The method of claim 1,further comprising: receiving a second transportation request from asecond passenger associated with the transportation service; anddetermining not to send the second transportation request to the driverin response to a determination that the exception criteria is not met.4. The method of claim 1, further comprising adjusting a baseline pricefor the transportation request based on the one or more exceptioncriteria received from the mobile device of the driver.
 5. The method ofclaim 1, wherein the one or more exception criteria indicates a minimumcost of the transportation request.
 6. The method of claim 1, whereinthe one or more exception criteria indicates a minimum average cost ofthe transportation request over time.
 7. The method of claim 1, whereinthe one or more exception criteria indicates a length of time forcomparison against an expected length of time of the transportationrequest.
 8. The method of claim 1, wherein the one or more exceptioncriteria specifies one or more locations.
 9. The method of claim 1,wherein the one or more exception criteria specifies one or moredistances.
 10. The method of claim 1, wherein the inactive statusindication specifies a finite duration of the inactive status.
 11. Anapparatus comprising: a communication interface; and at least oneprocessor to: receive an inactive status indication and one or moreexception criteria from a computing device of a driver associated with atransportation service; receive a transportation request from apassenger associated with the transportation service; and in response toa determination based on information included in the transportationrequest that the exception criteria is met, directing the transportationrequest to the driver.
 12. The apparatus of claim 11, wherein the one ormore exception criteria indicates a minimum cost of the transportationrequest.
 13. The apparatus of claim 11, wherein the one or moreexception criteria indicates a minimum average cost of thetransportation request over time.
 14. The apparatus of claim 11, whereinthe at least one processor is further to adjust a baseline price for thetransportation request based on the one or more exception criteriareceived from the mobile device of the driver.
 15. The apparatus ofclaim 11, wherein the one or more exception criteria specifies one ormore distances.
 16. At least one computer-readable non-transitory mediacomprising one or more instructions that when executed by at least oneprocessor configure the at least one processor to cause the performanceof operations comprising: receiving an inactive status indication andone or more exception criteria from a computing device of a driverassociated with a transportation service; receiving a transportationrequest from a passenger associated with the transportation service; andin response to a determination based on information included in thetransportation request that the exception criteria is met, directing thetransportation request to the driver.
 17. The media of claim 16, whereinthe one or more exception criteria indicates a minimum cost of thetransportation request.
 18. The media of claim 16, wherein the one ormore exception criteria indicates a minimum average cost of thetransportation request over time.
 19. The media of claim 16, wherein theinstructions are further to cause the performance of adjusting abaseline price for the transportation request based on the one or moreexception criteria received from the mobile device of the driver. 20.The media of claim 16, wherein the one or more exception criteriaspecifies one or more distances.